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Grady Booch defines a mixin as: 

"A class that embodies a single, focused behavior, used 
to augment the behavior of some other class via inher¬ 
itance; the behavior of a mixin is usually orthogonal to 
the behavior of the classes with which it is combined." 1 

There are always situations in which "mixing in" another 
class is the most straightforward thing to do. But mixins 
are generally thought of as requiring multiple inheri¬ 
tance, 2 which is the mechanism by which languages like 
CLOS supply them. Smalltalk, however, does not have 
multiple inheritance. Furthermore, 
multiple inheritance raises a host of 
issues, such as repeated inheri¬ 
tance—where the same superclass 
can be reached via more than route 
through the parent hierarchy. 

Instead, I’m going to take a sim¬ 
pler, more pragmatic approach. In 
this implementation, mixins are 
provi ded to a cl ass by addi ng a mes¬ 
sage, mixins, which replies with a collection of mixin 
objects. If an object which uses mixins does not under¬ 
stand a particular message, then each object in the mix¬ 
ins collection istried, in order. Technically, this is nottrue 
multiple inheritance because it provides only "interface 
inheritance'' and not "class inheritance." 

I n order for this to work, the Object class must be mod¬ 
ified* Ordinarily, I am loath to do this, but this change is 
very simple and foolproof. Honest. 

First, change the name of the existing doesNot- 
Understand: method in the Object class to originalDoesNot- 
Understand;. Then, add the foil owing method: 

doesNotUnderstand: aMessage 

"If the object has mixins, see if one responds to 
aMessage." 

(self class canUnderstand: #mixins) iff rue: [ 


You could alternatively create a class that overrides the doesNot¬ 
Understand: message selector of the Object class, and always sub- 
classfromthisHowever,thisrestrictstheutilityofmixins,sinceyou 
would not then beableto"mixin"to an existingclasshierarchy. 


self mixins do: [ :mixin | 

(mixin class canUnderstand: aMessage selector) 
ifTrue: [ 

^mixin perform: aMessage selector 
withArguments: 
aMessage arguments 

]■ 

]■ 

]■ 

"was not handled by mixin, so pass to original 
doesNotUnderstand handler" 

^self originalDoesNotUnderstand: 
aMessage 

The operation of this method is very 
simple. If the class of the object that 
generated the doesNotUnderstand: 
message selector understands the 
mixins message, then this message 
is sent to it. The reply is some kind of 
Collection, which is sent the do: mes¬ 
sage selector with a block argument. This block argument 
tests to see if an element of the Co I lection understands the 
message selector that the original object did not under¬ 
stand. As soon as such an element is found, it is sent the 
message selector, along with the original arguments. 

The m i xi ns may be put i n any type of co 11 ecti on. A si m- 
pleOrderedCollection may be used as the mixins object. A 
dictionary might also be used to gain named access to the 
individual mixin objects. 

Here is a simply and highly artificial, but illustrative, 
example of using mixins. A class, MixinTest, has a single 
instance variable called mixins. It has the following 
accessor: 

mixins 

^mixins 

and the following initialize method: 
initialize 

mixins :=Ordered Co 11 ecti on new. 
mixins add: (Date today). 


Multiple inheri tance raises 
a host of issues, such as 
repeated inheritance. 
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The i n i ti al i ze method sets the mixi ns i nstance vari abl e as 
an OrderedCol lection with a single element, a Date, which is 
today's. This in itial i ze method i s sent by the i nstance cre¬ 
ation method: 

new 

''super new initialize 

I nspecti ng the fol lowi ng statement causes the current day 
of the month to be displayed: 

MixinTest new dayOfMonth 

Additional levels of mixi ns can be added. Consider a class 
Mixin2Test, which isasubclass of MixinTest. Thisclass also 
has the instance creation method: 

new 

''super new initialize 
but the initialize method is 

initialize 
super initialize. 

mixins add: (Point x: 100 y: 50) 

By calling super initialize, the MixinTest object creates the 
mixins instance variable and adds a Date object to it. The 
Mixin2Test initialize method then adds a Point object to 
mixins. 

A Mixi n2Test object now understands messages for two 
mixin objects. For example: 

Mixin2Test new dayOfMonth 
Mixin2Test new x 

An object of any class may act as a mixin. However, an 
abstract mixin class is particularly powerful. An abstract 
mixin is a class that cannot be instantiated in isolation, 
because it requires another object or objects to provide 
methods for it. 

I’ll call the object that a mixin is added to the root 
object. A class for subclassing abstract mixin classes is 
cal led AbstractM ixi n. It hasa single instance variable called 
root, which has the accessors: 

root 

^root 

root: anObject 
root : = anObject 

It also has the class-side instance creation method: 

root: anObject 

''self new root: anObject 

Subclasses of AbstractMixin must declare their root object 
when they create a new instance. The root object is im¬ 
plicitly referred to by sending messages of the form: 

self root <some message for root object> 

Every AbstractMixin subclass should clearly document 
what methods it requi res its root object to provide. 

As an example of abstract mixins, I'll use one given by 


Seidewitz. 3 The abstract mixin class InterestMixin is a 
subclass of AbstractMixin and provides the incremental 
functionality of earning interest. It has a single instance, 
variable, rate, with the usual accessors, plus a method 
for computing interest earned: 

interestEarned: dt 

"root must provide a 'balance' method" 

^root balance* rate* dt 

An instance creation method sets both the rate and the 
root object: 

rate: aNumber root: anObject 

''(self root: anObject) rate: aNumber 

Another mixin class, this time a concrete mixin called 
AccountMixin with an instance variable called balance, 
provides basic account functional ity: 

deposit: aNumber 

balance := balance + aNumber 

withdraw: aNumber 

balance := balance - aNumber 

An instance creation method sets the current balance: 

balance: aNumber 

''(self new) balance: aNumber 

Now, I'll put these together in a new class called Savings- 
Accountlmplementation, which has an instance variable 
mixins with an accessor of the same name. All that is nec¬ 
essary is add the instance initialization method: 

balance: aBalance rate: aRate 
mixins :=Ordered Co I lection new. 
mixins add: (AccountMixin balance: aBalance). 
mixins add: (InterestMixin rate: aRate root: self). 

and the following cl ass- side instance creation method, 

balance: aBalance rate: aRate 

''self new balance: aBalance rate: aRate 

That's all there is to it! The AccountMixin object provides 
the implementation of the balance method, which is 
required by the InterestMixin. SavingsAccountlmplemen- 
tation does not have to supply anything. M 
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